When are observable states necessary?

In order to use commercial off-the-shelf (COTS) products, the engineer must be able to prove that the COTS product is equivalent to the specified design. In most cases, this requires observable states, which are usually not available, because the supplier may not know or may not want to disclose the internal states of the system. This paper first presents the following reasons for proving system equivalence: to reuse existing systems, to upgrade systems, to use COTS products, to replicate failures, to verify that a physical system conforms to its design, and to test evolving systems. Next, the paper presents the following techniques that have been used in lieu of proving system equivalence: Create multiple reset (or test) states and prove I/O equivalence with respect to all initial state pairs, implement built-in self-tests, use regression testing, define pre and post conditions, only use COTS products in places where you do not care about observable states, put a wrapper around COTS products, record the mode the system was in when the event of interest occurred, abstract the code into a state machine, build an observer to estimate the system states, and add extra outputs so that the states can be identified by examining the outputs. Finally, this paper gives examples where states are necessary and unnecessary in modeling systems. © 2006 Wiley Periodicals, Inc. Syst Eng 5: 228–240, 2006